The network element must authenticate all NTP messages received from NTP servers and peers.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-14671	NET0813	SV-41500r1_rule	ECSC-1	Medium

Description
Since NTP is used to ensure accurate log file timestamp information, NTP could pose a security risk if a malicious user were able to falsify NTP information. To launch an attack on the NTP infrastructure, a hacker could inject time that would be accepted by NTP clients by spoofing the IP address of a valid NTP server. To mitigate this risk, the time messages must be authenticated by the client before accepting them as a time source. Two NTP-enabled devices can communicate in either client-server mode or peer-to-peer mode (aka “symmetric mode”). The peering mode is configured manually on the device and indicated in the outgoing NTP packets. The fundamental difference is the synchronization behavior: an NTP server can synchronize to a peer with better stratum, whereas it will never synchronize to its client regardless of the client’s stratum. From a protocol perspective, NTP clients are no different from the NTP servers. The NTP client can synchronize to multiple NTP servers, select the best server and synchronize with it, or synchronize to the averaged value returned by the servers. A hierarchical model can be used to improve scalability. With this implementation, an NTP client can also become an NTP server providing time to downstream clients at a higher stratum level and of decreasing accuracy than that of its upstream server. To increase availability, NTP peering can be used between NTP servers. In the event the device looses connectivity to it upstream NTP server, it will be able to choose time from one of its peers. The NTP authentication model is opposite of the typical client-server authentication model. NTP authentication enables an NTP client or peer to authenticate time received from their servers and peers. It’s not used to authenticate NTP clients because NTP servers don’t care about the authenticity of their clients, as they never accept any time from them.

Description

Since NTP is used to ensure accurate log file timestamp information, NTP could pose a security risk if a malicious user were able to falsify NTP information. To launch an attack on the NTP infrastructure, a hacker could inject time that would be accepted by NTP clients by spoofing the IP address of a valid NTP server. To mitigate this risk, the time messages must be authenticated by the client before accepting them as a time source. Two NTP-enabled devices can communicate in either client-server mode or peer-to-peer mode (aka “symmetric mode”). The peering mode is configured manually on the device and indicated in the outgoing NTP packets. The fundamental difference is the synchronization behavior: an NTP server can synchronize to a peer with better stratum, whereas it will never synchronize to its client regardless of the client’s stratum. From a protocol perspective, NTP clients are no different from the NTP servers. The NTP client can synchronize to multiple NTP servers, select the best server and synchronize with it, or synchronize to the averaged value returned by the servers. A hierarchical model can be used to improve scalability. With this implementation, an NTP client can also become an NTP server providing time to downstream clients at a higher stratum level and of decreasing accuracy than that of its upstream server. To increase availability, NTP peering can be used between NTP servers. In the event the device looses connectivity to it upstream NTP server, it will be able to choose time from one of its peers. The NTP authentication model is opposite of the typical client-server authentication model. NTP authentication enables an NTP client or peer to authenticate time received from their servers and peers. It’s not used to authenticate NTP clients because NTP servers don’t care about the authenticity of their clients, as they never accept any time from them.

STIG	Date
Firewall Security Technical Implementation Guide - Cisco	2013-10-08

Details

Check Text ( C-39979r1_chk )
Review the device configuration and verify that it is authenticating the NTP messages received from the NTP server or peer. Authentication must be performed using either PKI (supported in NTP v4) or SHA-1 hashing algorithm. If SHA-1 is not supported by both the NTP client and server, then MD5 can be used. You should find a configuration similar to the example below: ntp server 10.1.0.5 key 1 source mgmt ntp server 10.1.0.8 key 1 source mgmt ntp authenticate ntp authentication-key 1 md5 ******** ntp trusted-key 1

Check Text ( C-39979r1_chk )

Review the device configuration and verify that it is authenticating the NTP messages received from the NTP server or peer. Authentication must be performed using either PKI (supported in NTP v4) or SHA-1 hashing algorithm. If SHA-1 is not supported by both the NTP client and server, then MD5 can be used. You should find a configuration similar to the example below:

ntp server 10.1.0.5 key 1 source mgmt
ntp server 10.1.0.8 key 1 source mgmt
ntp authenticate
ntp authentication-key 1 md5 ********
ntp trusted-key 1

Fix Text (F-14132r1_fix)
Configure the device to authenticate all received NTP messages using either PKI (supported in NTP v4) or SHA-1 hashing algorithm. If SHA-1 is not supported by this client or the NTP peer or server, then MD5 can be used.